home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0052.001 < prev    next >
Text File  |  1990-09-23  |  4KB  |  104 lines
  1. Document: FSC-0052
  2. Version:  001
  3. Date:     23-Sep-90
  4.  
  5.  
  6.                                       ZPTH
  7.                                       ----
  8.  
  9.                     A proposal for making the PATH zone aware
  10.  
  11.                                Gerard van der Land
  12.                                 FidoNet 2:283/1.5
  13.  
  14.  
  15.  
  16. Status of this document:
  17.  
  18.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  19.      and requests discussion and suggestions for improvements.
  20.      Distribution of this document is unlimited.
  21.  
  22.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  23.      Software.
  24.  
  25.  
  26.  
  27.            The PATH line can be a more accurate source of  information than
  28.      the SEEN-BY  line to determine  if a message  is a duplicate.  TosScan
  29.      with Circular  PATH Protection  (CPP) enabled  will consider  messages
  30.      that already have your address in  them as duplicates. This works fine
  31.      in  conferences  that  are  distributed   within  one  zone,  but   in
  32.      conferences spread across zones it can cause problems.
  33.  
  34.            Unlike SEEN-BY lines,  PATH lines are  not stripped at the  zone
  35.      gate,  because  they have  a very  important  purpose: to  be  able to
  36.      determine the used echomail topology and troubleshooting, like finding
  37.      the cause of duplicate messages. Unfortunately this also means that if
  38.      a message is entered  at 1:283/1 and my boss would  be running TosScan
  39.      with CPP  enabled, the  message would  be considered  as a  duplicate,
  40.      because "283/1" is already in the PATH lines.
  41.  
  42.            If  such  messages are  not deleted  but  stored in  a duplicate
  43.      directory, you will of course notice this happen and  disable CPP, but
  44.      you can't know  if messages never reach your  system because they were
  45.      deleted for the same reason by another node that had CPP enabled.
  46.  
  47.             That's why I have the following  proposal. If a message travels
  48.      from one zone to another, the zone gateway should move all information
  49.      in the current PATH lines to kludge lines with the following format:
  50.  
  51.            ^aZPTH: <origin zone>:<old path info>
  52.  
  53.            The receiving system in the destination  zone creates a new PATH
  54.      with his address in it.
  55.  
  56.            There is no need  to support or allow 4D addresses  in the ZPTH,
  57.      since it is only supplements the existing PATH lines.
  58.  
  59.  
  60.      Simple sample
  61.      -------------
  62.  
  63.            A message originating at 1:154/40 arrives at 1:260/340...
  64.  
  65.      ^aPATH: 154/40 970 9 157/200 265/7 13/13 260/340
  66.  
  67.            ...and is sent to Europe. This is how I would see it:
  68.  
  69.      ^aZPTH: 1:154/40 970 9 157/200 265/7 13/13 260/340
  70.      ^aPATH: 310/11 507/1 512/0 280/0 283/1
  71.  
  72.            Now suppose that  283/1 would gate it  to zone 3, it  would look
  73.      like this when it gets there:
  74.  
  75.      ^aZPTH: 1:154/40 970 9 157/200 265/7 13/13 260/340
  76.      ^aZPTH: 2:310/11 507/1 512/0 280/0 283/1
  77.  
  78.            The receiving node  in zone 3 now  creates a new PATH  line with
  79.      his address in it.
  80.  
  81.      Advantages
  82.      ----------
  83.  
  84.        1) It enables  Circular PATH  Protection (CPP)  on conferences  that
  85.           travel  across  zones  without  the  risk  of messages  that  are
  86.           erroneous considered as duplicates and deleted.
  87.  
  88.        2) A  zone gate can  optionally parse the  ZPTH lines to  see if his
  89.           zone or the destination  zone has already seen the  message (CZP,
  90.           Circular ZPATH Protection), which means  a duplicate message will
  91.           never go to another zone. Ofcourse this could only be used  if it
  92.           sure that messages shouldn't re-enter a zone.
  93.  
  94.        3) You  get  a  much better  view  on  the  used echomail  topology,
  95.           sometimes it is  very hard to see  where a message goes  from one
  96.           zone to another.
  97.  
  98.        4) It will not screw up with any  echomail processor as long as they
  99.           ignore unknown kludges. Only nodes gating echomail from  one zone
  100.           to another would need to have a processor that supports the  ZPTH
  101.           kludge.
  102.  
  103.        5) It will hardly increase the size of compressed mail archives.
  104.